]> dgit.raspbian.org Git - gnome-shell.git/log
gnome-shell.git
5 years agoUpdate Finnish translation
Jiri Grönroos [Sun, 21 Feb 2021 13:41:18 +0000 (13:41 +0000)]
Update Finnish translation

5 years agoUpdate Indonesian translation
Kukuh Syafaat [Sun, 21 Feb 2021 13:22:01 +0000 (13:22 +0000)]
Update Indonesian translation

5 years agoUpdate Romanian translation
Daniel Șerbănescu [Sun, 21 Feb 2021 11:30:45 +0000 (11:30 +0000)]
Update Romanian translation

5 years agoschema: Enable extension version validation by default
Evan Welsh [Sat, 20 Feb 2021 20:25:00 +0000 (12:25 -0800)]
schema: Enable extension version validation by default

Previously this was disabled to avoid requiring extensions to manually
update on each release. For 40 this behavior will likely be too unstable
for most users.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1706>

5 years agoUpdate Turkish translation
Emin Tufan Çetin [Fri, 19 Feb 2021 22:12:55 +0000 (22:12 +0000)]
Update Turkish translation

5 years agoUpdate Swedish translation
Anders Jonsson [Fri, 19 Feb 2021 22:08:24 +0000 (22:08 +0000)]
Update Swedish translation

5 years agoUpdate Brazilian Portuguese translation
Enrico Nicoletto [Fri, 19 Feb 2021 21:10:35 +0000 (21:10 +0000)]
Update Brazilian Portuguese translation

5 years agoUpdate Portuguese translation
Hugo Carvalho [Fri, 19 Feb 2021 20:55:11 +0000 (20:55 +0000)]
Update Portuguese translation

5 years agoUpdate Catalan translation
Jordi Mas [Fri, 19 Feb 2021 19:21:59 +0000 (20:21 +0100)]
Update Catalan translation

5 years agowelcomeDialog: Hide overview when taking tour
Florian Müllner [Fri, 19 Feb 2021 16:11:14 +0000 (17:11 +0100)]
welcomeDialog: Hide overview when taking tour

The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1699>

5 years agowindowPreview: Add scaled extra size to chromeWidths() and chromeHeights
Jonas Dreßler [Mon, 8 Feb 2021 18:06:37 +0000 (19:06 +0100)]
windowPreview: Add scaled extra size to chromeWidths() and chromeHeights

Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().

Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>

5 years agowindowPreview: Scale up by the same extra size for every window
Jonas Dreßler [Mon, 8 Feb 2021 18:02:23 +0000 (19:02 +0100)]
windowPreview: Scale up by the same extra size for every window

Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.

So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>

5 years agowindowPreview: Use a proper spacing between icon and title
Jonas Dreßler [Tue, 9 Feb 2021 11:18:29 +0000 (12:18 +0100)]
windowPreview: Use a proper spacing between icon and title

Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).

So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.

Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>

5 years agowindowManager: Keep a minimum number of workspaces
Florian Müllner [Tue, 16 Feb 2021 18:37:38 +0000 (19:37 +0100)]
windowManager: Keep a minimum number of workspaces

The scaled down workspace in the window picker looks lonely when there's
no adjacent workspace peeking in. Avoid that by always keeping a minimum
of two workspaces.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnails: Only show for more than two workspaces
Florian Müllner [Tue, 16 Feb 2021 19:15:21 +0000 (20:15 +0100)]
workspaceThumbnails: Only show for more than two workspaces

As adjacent workspaces now peek into the window picker, the first
two workspaces are already accessible without the minimap. Hide
it in that case to give more space to the window picker, and to
not clutter the overview for users who aren't using workspaces.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnail: Do not update scale while collapsing
Florian Müllner [Wed, 17 Feb 2021 19:13:22 +0000 (20:13 +0100)]
workspaceThumbnail: Do not update scale while collapsing

The scale property tracks the relative size at which we display thumbnails
given the space we have available.

That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.

Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnails: Delay workspace removal while collapsing
Florian Müllner [Wed, 17 Feb 2021 08:54:14 +0000 (09:54 +0100)]
workspaceThumbnails: Delay workspace removal while collapsing

Animating a thumbnail removal while also collapsing the minimap
itself doesn't look good, so keep the stale thumbnail until the
minimap is hidden.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnails: Don't animate thumbnail additions while hidden
Florian Müllner [Tue, 16 Feb 2021 21:33:28 +0000 (22:33 +0100)]
workspaceThumbnails: Don't animate thumbnail additions while hidden

This is not just an obvious mini-optimization, it also ensures that we
don't start showing the minimap with an ongoing thumbnail transition.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnails: Animate showing/hiding
Florian Müllner [Tue, 16 Feb 2021 21:03:29 +0000 (22:03 +0100)]
workspaceThumbnails: Animate showing/hiding

Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.

However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.

Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumnails: Add :should-show property
Florian Müllner [Tue, 16 Feb 2021 19:40:43 +0000 (20:40 +0100)]
workspaceThumnails: Add :should-show property

We currently have two components that show or hide the minimap:

 - the thumbnails hide themselves in case of a single static workspace
 - overview controls show the minimap when no search is active

That obviously doesn't work correctly.

To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnail: Base n-workspaces on number of thumbs
Florian Müllner [Wed, 17 Feb 2021 19:31:33 +0000 (20:31 +0100)]
workspaceThumbnail: Base n-workspaces on number of thumbs

It's what we base our size request on, and what we actually allocate.
The difference usually doesn't matter right now, but will soon when
we animate the minimap itself.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agoworkspaceThumbnails: Actually use vscale parameter
Florian Müllner [Tue, 16 Feb 2021 22:06:37 +0000 (23:06 +0100)]
workspaceThumbnails: Actually use vscale parameter

We pass two scales to setScale(), but only use the first one for
both horizontal and vertical scaling. We'll soon have a use case
for using a different scale for each dimension, so start using
both parameters.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>

5 years agotheme/window-picker: Fixup box-shadow of overview workspace backgrounds
Jonas Dreßler [Thu, 18 Feb 2021 21:10:02 +0000 (22:10 +0100)]
theme/window-picker: Fixup box-shadow of overview workspace backgrounds

A small mistake snuck in right before landing the previous commit and
the box-shadow was moved 4px vertically above the wallpaper instead of
below it. Fix that and put it 4px below the wallpaper.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1697>

5 years agotheme/window-picker: Add box-shadow to the workspace background
Jonas Dreßler [Mon, 8 Feb 2021 15:43:32 +0000 (16:43 +0100)]
theme/window-picker: Add box-shadow to the workspace background

According to the GNOME 40 mockups, add a box-shadow to the workspace
background. For this to work, we also need a background-color (St
limitations), and to make sure that background-color doesn't bleed over
the rounded corners of the wallpaper, we also need to tell St to use a
border-radius and clip the background-color painting using a rounded
path.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>

5 years agoworkspace: Round the corners of the wallpaper
Jonas Dreßler [Mon, 8 Feb 2021 15:33:06 +0000 (16:33 +0100)]
workspace: Round the corners of the wallpaper

As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.

To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.

Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>

5 years agoUpdate Ukrainian translation
Yuri Chornoivan [Thu, 18 Feb 2021 20:27:11 +0000 (20:27 +0000)]
Update Ukrainian translation

5 years agoUpdate Slovenian translation
Matej Urbančič [Thu, 18 Feb 2021 20:24:21 +0000 (20:24 +0000)]
Update Slovenian translation

5 years agooverviewControls: Add shortcut for shifting through overview
Florian Müllner [Sat, 13 Jun 2020 11:26:09 +0000 (13:26 +0200)]
overviewControls: Add shortcut for shifting through overview

This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1695>

5 years agoworkspacesView: Disable mouse drag to switch workspaces
Georges Basile Stavracas Neto [Fri, 8 Jan 2021 20:25:45 +0000 (17:25 -0300)]
workspacesView: Disable mouse drag to switch workspaces

During the user research, it was found that users would instinctively
drag the workspace horizontally but would often, in the process,
accidentally drag a window.

Disable dragging workspaces using the cursor for now.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3742
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1694>

5 years agoUpdate Brazilian Portuguese translation
Rafael Fontenelle [Thu, 18 Feb 2021 01:31:36 +0000 (01:31 +0000)]
Update Brazilian Portuguese translation

5 years agodash: Put the dot back into its box
Florian Müllner [Wed, 17 Feb 2021 00:46:04 +0000 (01:46 +0100)]
dash: Put the dot back into its box

When commit 3a9acb96 moved around padding to extend the clickable
area to the screen edge, it reduced the inner padding too much and
the running indicator ended up outside the highlighted area.

Adjust the padding to put it back into its place.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1693>

5 years agoUpdate Slovenian translation
Matej Urbančič [Wed, 17 Feb 2021 18:54:50 +0000 (18:54 +0000)]
Update Slovenian translation

5 years agokeyboard: Handle edge drag gesture cancellation
Carlos Garnacho [Sun, 14 Feb 2021 09:26:38 +0000 (10:26 +0100)]
keyboard: Handle edge drag gesture cancellation

Hide the keyboard again if the gesture happens to stay/return
within it's activation threshold.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agokeyboard: Make OSK follow gesture progress
Carlos Garnacho [Thu, 11 Feb 2021 23:54:55 +0000 (00:54 +0100)]
keyboard: Make OSK follow gesture progress

With all other gestures offering live feedback of progress, seems
to make sense to update the "swipe from bottom edge to show OSK"
gesture as well.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agokeyboard: Use translation-y property for focus window animations
Carlos Garnacho [Thu, 11 Feb 2021 23:53:21 +0000 (00:53 +0100)]
keyboard: Use translation-y property for focus window animations

Just the intermediate state, we still need to synchronize visual and
real window position after the animation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agokeyboard: Move monitor management to KeyboardController
Carlos Garnacho [Thu, 11 Feb 2021 15:44:28 +0000 (16:44 +0100)]
keyboard: Move monitor management to KeyboardController

Instead of setting it deep down, manage it at the higher level.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agokeyboard: Simplify focus window tracking
Carlos Garnacho [Thu, 11 Feb 2021 14:36:42 +0000 (15:36 +0100)]
keyboard: Simplify focus window tracking

Keep the focus window in a single field, and optionally animate
depending on keyboard visibility.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agoedgeDragAction: Add signal to notify about progress
Carlos Garnacho [Thu, 11 Feb 2021 13:15:25 +0000 (14:15 +0100)]
edgeDragAction: Add signal to notify about progress

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agokeyboard: Drop layoutManager's keyboard-visible-changed
Carlos Garnacho [Thu, 11 Feb 2021 13:10:48 +0000 (14:10 +0100)]
keyboard: Drop layoutManager's keyboard-visible-changed

Since now the signal is emitted and handled all within keyboard.js,
use an internal signal to manage keyboard visibility and gesture
enablement.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agowindowManager: Move OSK gesture to KeyboardManager
Carlos Garnacho [Thu, 11 Feb 2021 12:41:16 +0000 (13:41 +0100)]
windowManager: Move OSK gesture to KeyboardManager

It would be nice to get finer control over the keyboard slide
gesture and animation. Move the gesture bits so they are together
at keyboard.js.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agolayout: Move keyboard slide animation to keyboard
Carlos Garnacho [Thu, 11 Feb 2021 12:08:47 +0000 (13:08 +0100)]
layout: Move keyboard slide animation to keyboard

The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.

This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.

The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>

5 years agooverview: Synchronize panel opacity with overview leave animation
Carlos Garnacho [Tue, 16 Feb 2021 23:57:13 +0000 (00:57 +0100)]
overview: Synchronize panel opacity with overview leave animation

Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agooverview: Clean up dead code
Carlos Garnacho [Fri, 12 Feb 2021 11:24:12 +0000 (12:24 +0100)]
overview: Clean up dead code

These unused functions accessed undefined functions on a now undefined
variable/class. This vestigial code can go away.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agooverview: Make 3fg vertical swipes bring overview and app grid
Carlos Garnacho [Mon, 4 Jan 2021 15:23:45 +0000 (16:23 +0100)]
overview: Make 3fg vertical swipes bring overview and app grid

The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.

Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agooverviewControls: Add "gesture-in-progress" property on the state adjustment
Carlos Garnacho [Thu, 11 Feb 2021 23:20:31 +0000 (00:20 +0100)]
overviewControls: Add "gesture-in-progress" property on the state adjustment

This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agoworkspacesView: Initialize/update swipe orientation before gesture
Carlos Garnacho [Thu, 11 Feb 2021 23:24:13 +0000 (00:24 +0100)]
workspacesView: Initialize/update swipe orientation before gesture

Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.

But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).

Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agoworkspacesView: Check for primaryView being null
Carlos Garnacho [Mon, 4 Jan 2021 16:42:26 +0000 (17:42 +0100)]
workspacesView: Check for primaryView being null

This is possible according to the getter, and triggers warnings
seen when going back from overview via gestures.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agoswipeTracker: Reject touch swipes in the wrong directions
Carlos Garnacho [Wed, 3 Feb 2021 15:54:25 +0000 (16:54 +0100)]
swipeTracker: Reject touch swipes in the wrong directions

We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touch swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.

So, look for the direction of the touch events and look if it matches
the expected orientation before accepting the gesture.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agoswipeTracker: Try harder to start touchpad gestures with a direction
Carlos Garnacho [Fri, 12 Feb 2021 11:13:57 +0000 (12:13 +0100)]
swipeTracker: Try harder to start touchpad gestures with a direction

Make the touchpad gesture keep track of its state, and enter in a
rejected state if the swipe is happening in the wrong direction.

Effectively, this means touchpad gestures are locked on a single
direction, and horizontal+vertical swipeTrackers won't be handling
events at the same time.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agoswipeTracker: Reject touchpad swipes in the wrong directions
Florian Müllner [Tue, 9 Jun 2020 23:45:08 +0000 (01:45 +0200)]
swipeTracker: Reject touchpad swipes in the wrong directions

We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touchpad swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.

So, look for the direction of the swipe events and look if it matches
the expected orientation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>

5 years agodnd: Remove pointless scale factor from restore position
Sebastian Keller [Wed, 17 Feb 2021 00:07:38 +0000 (01:07 +0100)]
dnd: Remove pointless scale factor from restore position

Since 629b7394 we don't use the preferred size anymore, but the original
allocation, so this scale factor would always be 1.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>

5 years agodnd: Also consider indirect scaling of dnd actor
Sebastian Keller [Wed, 17 Feb 2021 00:00:27 +0000 (01:00 +0100)]
dnd: Also consider indirect scaling of dnd actor

Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>

5 years agosearchController: Get rid of activePage reference in key handling
Marco Trevisan (Treviño) [Wed, 17 Feb 2021 01:31:32 +0000 (02:31 +0100)]
searchController: Get rid of activePage reference in key handling

Even if activePage has been removed as part of commit 27627bd40, we've
still a reference of it in key press handler.

Given that there's no anymore an active page to redirect input to,
remove these references, so that can be handled in the proper view to
implement key-navigation.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1688>

5 years agoworkspace: Ensure that _createBestLayout() always returns a layout
Sebastian Keller [Tue, 16 Feb 2021 12:37:17 +0000 (13:37 +0100)]
workspace: Ensure that _createBestLayout() always returns a layout

When opening a large number of windows, the computed space and scale for
a layout can become negative due to the per-row/per-column spacing. This
is smaller than the initial values of lastSpace and lastSpace, leading
to a null return which then causes all sorts of other issues resulting
in the workspace becoming invisible.

This change ensures that the function always returns a layout, even if
it may look a bit broken and does not conform to the scale/space
requirements which are impossible to fulfill for the given number of
windows. It's better than displaying nothing, since it allows users to
move/close windows and restore this to a more usable state.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3730

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1685>

5 years agotheme: Use the same style for dash tooltips as for window captions
Sebastian Keller [Tue, 16 Feb 2021 00:28:00 +0000 (01:28 +0100)]
theme: Use the same style for dash tooltips as for window captions

Both serve a similar function but had different styles. Since these two
can now be seen next to each other, the visual difference is quite
noticeable.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3727

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1681>

5 years agogdm: Override any other lower-priority service message on error
Marco Trevisan (Treviño) [Tue, 16 Feb 2021 02:56:09 +0000 (03:56 +0100)]
gdm: Override any other lower-priority service message on error

When we got an error, all the other HINT or INFO messages are not useful
anymore and delaying to show them is just a waste of time and may be
even wrong in scenarios with fast authentication devices.

An example are the fingerprint devices, where the user may touch the
sensor repeatedly while we may still show the "touch the sensor" hint
instead of notifying of possible errors.

So, in case we got an error override all the other errors coming from
the same service with lower priority.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agogdm: Filter service non-error messages on verification stopped or failed
Marco Trevisan (Treviño) [Tue, 16 Feb 2021 02:45:14 +0000 (03:45 +0100)]
gdm: Filter service non-error messages on verification stopped or failed

Once the verification has been stopped or has failed all the messages
that are not of error type are just not needed or wrong to show.
For example, in the fingerprint case we may still show the hint to swipe
or touch the device, while the fingerprint PAM service has already been
stopped.

So filter them by adding a new function that adds a null message to the
queue, overriding all the messages that have a lower priority.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agogdm: Add ability to queue a message overriding ones with less priority
Marco Trevisan (Treviño) [Tue, 16 Feb 2021 02:08:38 +0000 (03:08 +0100)]
gdm: Add ability to queue a message overriding ones with less priority

There are cases in which a service may want to override a message with
one coming with higher priority, for example an info or hint message
isn't useful anymore if we've already got an error message.

In the same way when a service has been stopped we don't care anymore
showing its info or hint messages, while it still may be relevant to show
errors.

An example is the fingerprint service that may emit errors quickly while
the hints messages should not be kept around when an error is already
queued or when the service has been stopped.

So, add function that allows to override queued messages based by their
type that follows this policy:
 - Messages coming from different services are always preserved in
   their original order.
 - Messages (from the same service) with a priority equal or higher than
   the last queued one are preserved.
 - Messages matching completely the last queued are dropped in favor of
   this one.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agogdm: Keep messages in queue until we've not fully processed them
Marco Trevisan (Treviño) [Tue, 16 Feb 2021 01:00:41 +0000 (02:00 +0100)]
gdm: Keep messages in queue until we've not fully processed them

It can be convenient to get the currently showing message in order to
replace or remove it in case it's not needed anymore.

So simplify the message queue handling by only depending on a single
local variable (_messageQueue) and redefining hasPendingMessages
depending on its content.

Now messages are kept in queue till they are not fully processed and the
first message is always the one currently shown.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agogdm: Compress fingerprint failures events using a timeout
Marco Trevisan (Treviño) [Tue, 16 Feb 2021 03:18:18 +0000 (04:18 +0100)]
gdm: Compress fingerprint failures events using a timeout

When a fingerprint failure event happens we may also soon receive a
conversation-stopped event with an error message (such as in the case
we hit the MAXRETRIES value), but this is going to be ignored in case we
are too quick in consider the first failure a verification-failed event
because that implies disconnecting from all the events and then ignoring
such signals.

To prevent this, add a small timeout before failing the verification so
that if we get a further event we will process it.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agogdm: Don't try to retry authenticating when the service is unavailable
Marco Trevisan (Treviño) [Mon, 15 Feb 2021 19:59:57 +0000 (20:59 +0100)]
gdm: Don't try to retry authenticating when the service is unavailable

In the case a service is not available (as it can be in the fingereprint
case when a supported reader is available but has not enrolled prints)
we were trying indefinitely to restart it, however this can lead to
troubles since commit 7a2e629b as when the service conversation was
stopped we had no way to figure out this case and we'd end up to
eventually fail the whole authentication.

However, in such cases the PAM services are expected to return a
PAM_AUTHINFO_UNAVAIL and gdm to handle it, emitting service-unavailable
signal.

So connect to ::service-unavailable and keep track of the unavailable
services so that we can avoid retrying with them.
In case such service is not the foreground one, we can just silently
ignore the error as we did before commit 7a2e629b, without bothering
failing the whole verification.

In case we got a valid error message on service-unavailable, we also
show it, this is normally not happening unless GDM isn't redirecting
here other kind of problems (such as MAXTRIES) which are supposed to
stop the authentication stopping any further retry.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3734
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>

5 years agoappDisplay: Use icon-size instead of width/height for system actions
Jonas Dreßler [Tue, 16 Feb 2021 13:17:55 +0000 (14:17 +0100)]
appDisplay: Use icon-size instead of width/height for system actions

When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>

5 years agoappDisplay: Use new indentation style
Jonas Dreßler [Tue, 16 Feb 2021 13:26:12 +0000 (14:26 +0100)]
appDisplay: Use new indentation style

Otherwise eslint will complain about the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>

5 years agowindowPreview: Consider chrome overlaps when offscreening for opacity
Sebastian Keller [Tue, 16 Feb 2021 10:45:50 +0000 (11:45 +0100)]
windowPreview: Consider chrome overlaps when offscreening for opacity

The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>

5 years agoworkspacesView: Don't invalidate allocation before using it for gesture
Sebastian Keller [Tue, 16 Feb 2021 02:50:52 +0000 (03:50 +0100)]
workspacesView: Don't invalidate allocation before using it for gesture

Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>

5 years agodnd: Set dnd actor size instead of scaling it when reparenting
Sebastian Keller [Mon, 15 Feb 2021 23:54:37 +0000 (00:54 +0100)]
dnd: Set dnd actor size instead of scaling it when reparenting

Previously the actor could end up using its natural size and then get
scaled down to its allocation before reparenting. This however could
affect the layout of the widget due to the larger size. To ensure the
widget looks the same after reparenting set the size to its original
size.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3717

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1680>

5 years agost: Keep weak ref on texture cache bound texture source
Carlos Garnacho [Fri, 12 Feb 2021 22:10:25 +0000 (23:10 +0100)]
st: Keep weak ref on texture cache bound texture source

We don't keep any ref on it, so it might leave us with a dangling
pointer here.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3491
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1672>

5 years agogdm: Fail and restart verification on conversation stopped for all services
Marco Trevisan (Treviño) [Mon, 8 Feb 2021 17:57:06 +0000 (18:57 +0100)]
gdm: Fail and restart verification on conversation stopped for all services

Currently when the foreground service conversation stops we increase the
verification failed count and try to start it again, while if a
background service has been stopped we just ignore it.

This is causing a various number of issues, for example in the case of
the fingerprint authentication service, it is normally configured to die
after a timeout, and we end up never restarting it (while the UI still
keeps showing to the user the message about swipe/touch the device).

So, in such case let's just consider it a "soft" verification failure
that doesn't increase the failures count but will cause us to reset the
UI and try to restart the authentication (and so the affected service).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agoauthPrompt: Bump the user verifier timeout when wiggling the message
Marco Trevisan (Treviño) [Mon, 8 Feb 2021 18:34:09 +0000 (19:34 +0100)]
authPrompt: Bump the user verifier timeout when wiggling the message

Wiggle may make the error message to be visible for less time so provide
the auth prompt an API to increase the timeout to be used for showing a
message in some cases.

This could be reworked when we'll have a proper asyn wiggle function so
that we could just make the user verifier to "freeze", then await for
the wiggle transition to complete and eventually release the verifier.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agoauthPrompt: Wiggle error messages coming from the Fingerprint service
Marco Trevisan (Treviño) [Mon, 1 Feb 2021 18:44:00 +0000 (19:44 +0100)]
authPrompt: Wiggle error messages coming from the Fingerprint service

When error messages are coming from the fingerprint service they are actual
failures due to an user input in some device, in so in such case we
can highlight this by using a wiggle effect.

This mimics what has been done in gnome-control-center fingerprint panel
and part of [1].

[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agoauthPrompt: Only wiggle the entry on failures coming from the querying service
Marco Trevisan (Treviño) [Mon, 1 Feb 2021 18:39:03 +0000 (19:39 +0100)]
authPrompt: Only wiggle the entry on failures coming from the querying service

Currently whenever an authentication failure happens we wiggle the
entry, however this may not be related to the service which failed.

For example if the fingerprint authentication failed for whatever reason,
there's no point to wiggle the text input as it's something unrelated to it.

So, only apply the wiggle effect to the entry in case the failure is
coming from the querying service.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agogdm: Expose the source serviceName for messages and verification failures
Marco Trevisan (Treviño) [Mon, 1 Feb 2021 18:36:49 +0000 (19:36 +0100)]
gdm: Expose the source serviceName for messages and verification failures

By giving to the AuthPrompt information regarding the source service
name (and so the ability to know whether it's a foreground service) can
give it the ability to behave differently.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agogdm: Count fingerprint authentication failures in fail counter
Marco Trevisan (Treviño) [Mon, 1 Feb 2021 17:40:03 +0000 (18:40 +0100)]
gdm: Count fingerprint authentication failures in fail counter

Fingerprint PAM module can have multiple failures during a runtime
and we rely on the pam module configuration for the maximum allowed
retries.

However, while that setting should be always followed, we should never
ignore the login-screen's allowed-failures setting that can provide
a lower value.

So, once we have a fingerprint failure let's count it to increase our
internal fail counter, and when we've reached the limit we can emit a
verification-failed signal to our clients.

As per this we need also to ignore any further 'info' messages that we
could receive from the fingerprint service, as it may be configured to
handle more retries than us and they might arrive before we have
cancelled the verification session.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agogdm: Increase the verification failed counter once we've a failure
Marco Trevisan (Treviño) [Mon, 8 Feb 2021 17:43:16 +0000 (18:43 +0100)]
gdm: Increase the verification failed counter once we've a failure

Decouple the verification failure count increase from
_verificationFailed as there are some cases in which we may want to
increase it without emitting a verification-failed signal.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agogdm: Always show fingerprint error messages
Marco Trevisan (Treviño) [Tue, 24 Nov 2020 18:19:22 +0000 (19:19 +0100)]
gdm: Always show fingerprint error messages

When the login/lock screen is shown the error messages for background
services are always ignored.

However, in case the service is the fingerprint authentication method
we still want to be able to show error messages to inform the user
about what failed, and eventually that the max retries (that may be
different from the login screen configuration) has been reached.

This handles partially the design issue [1] related to the login/lock
screen fingerprint authentication.

Eventually we want to use pam extensions to use clearer and parse-able
messages, however in the case of the fingerprint service we can be sure
that the fprint PAM module will only send errors on auth failures.

[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agoShellUserVerifier: Add method to check if the service name is fingerprint
Marco Trevisan (Treviño) [Mon, 8 Feb 2021 16:07:45 +0000 (17:07 +0100)]
ShellUserVerifier: Add method to check if the service name is fingerprint

We have multiple places where we check if we're handling a fingerprint
event, so let's add a common public function so that it can be used also
by the authPrompt.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1652>

5 years agoblur-effect: Don't use stage view when drawing off-stage
Jonas Dreßler [Sat, 13 Feb 2021 15:07:22 +0000 (16:07 +0100)]
blur-effect: Don't use stage view when drawing off-stage

When we're painting off-stage, for example because we're screencasting
or taking a screenshot, there won't be a stage-view associated with the
paint context. The BlurEffect previously didn't handle that case and
would crash.

Fix that and handle that case by assuming the scale is 1 and not
offsetting the rectangle we blit from the draw framebuffer.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1673>

5 years agoUpdated Spanish translation
Daniel Mustieles [Mon, 15 Feb 2021 09:48:39 +0000 (10:48 +0100)]
Updated Spanish translation

5 years agoUpdate Serbian translation
Марко Костић [Mon, 15 Feb 2021 08:16:57 +0000 (08:16 +0000)]
Update Serbian translation

5 years agoshell: Drop shell_global_sync_pointer()
Carlos Garnacho [Fri, 18 Dec 2020 14:30:04 +0000 (15:30 +0100)]
shell: Drop shell_global_sync_pointer()

This is now unused, and shouldn't be used anymore.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agomessageTray: Drop hack to keep track of X11
Carlos Garnacho [Fri, 18 Dec 2020 14:11:34 +0000 (15:11 +0100)]
messageTray: Drop hack to keep track of X11

This is here to cater for lost events while the pointer wanders
into untracked shell UI (thus not part of the input region under
X11). Let mutter handle this situation instead.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agowindowManager: Drop sync_pointer() after relayouts
Carlos Garnacho [Fri, 18 Dec 2020 12:27:39 +0000 (13:27 +0100)]
windowManager: Drop sync_pointer() after relayouts

We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agomessageList: Drop sync_pointer() after relayouts
Carlos Garnacho [Fri, 18 Dec 2020 12:25:47 +0000 (13:25 +0100)]
messageList: Drop sync_pointer() after relayouts

We should trust the Clutter machinery here, as it has code to trigger
focus changes triggered by relayouts.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agooverview: Avoid sync_pointer after pop_modal()
Carlos Garnacho [Fri, 18 Dec 2020 12:24:55 +0000 (13:24 +0100)]
overview: Avoid sync_pointer after pop_modal()

This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agograbHelper: Avoid sync_pointer after pop_modal()
Carlos Garnacho [Fri, 18 Dec 2020 12:22:50 +0000 (13:22 +0100)]
grabHelper: Avoid sync_pointer after pop_modal()

This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agodnd: Avoid sync_pointer after pop_modal()
Carlos Garnacho [Fri, 18 Dec 2020 12:20:18 +0000 (13:20 +0100)]
dnd: Avoid sync_pointer after pop_modal()

This is only necessary for the X11 backend (as grabs triggered by other
clients leave GNOME Shell oblivious of the actual pointer position), but
is now handled inside Mutter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1556>

5 years agoUpdate Punjabi translation
A S Alam [Sun, 14 Feb 2021 00:50:19 +0000 (00:50 +0000)]
Update Punjabi translation

5 years agoUpdate Hungarian translation
Balázs Meskó [Sat, 13 Feb 2021 23:32:09 +0000 (23:32 +0000)]
Update Hungarian translation

5 years agost/scroll-view-fade: Fix vertical top fading
Sebastian Keller [Sat, 13 Feb 2021 20:13:57 +0000 (21:13 +0100)]
st/scroll-view-fade: Fix vertical top fading

The fade for the vertical top edge was calculating the fade ratio for a
larger height (up to where the bottom fade starts) than it was
displaying.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1674>

5 years agoosk-layouts: Add additional keys to Thai layout
Panawat Wong-kleaw [Tue, 1 Sep 2020 08:05:43 +0000 (08:05 +0000)]
osk-layouts: Add additional keys to Thai layout

Add Anghankhu (๚), Fongman (๏), Khomut (๛), and Yamakkan ( ๎) keys.

These keys do not exist in most, if not all, Thai physical keyboards,
but may be used by those who study ancient Thai texts. However,
they are an optional part of the TIS-820-2538 spec[0].

[0] https://www.nectec.or.th/it-standards/std820/std820.html

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>

5 years agoosk-layouts: Add a shift level to Thai layout
Panawat Wong-kleaw [Tue, 1 Sep 2020 07:32:01 +0000 (07:32 +0000)]
osk-layouts: Add a shift level to Thai layout

It is currently missing entirely from the generated layout.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3106

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1427>

5 years agowindowManager: Do not set Wacom LED state through g-s-d
Carlos Garnacho [Fri, 6 Mar 2020 14:34:00 +0000 (15:34 +0100)]
windowManager: Do not set Wacom LED state through g-s-d

This piece of machinery is going away, in favor of the own kernel's
support.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1075>

5 years agolookingGlass: Let history trim input
Lucas Werkmeister [Thu, 11 Feb 2021 18:44:03 +0000 (19:44 +0100)]
lookingGlass: Let history trim input

Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.

The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>

5 years agorunDialog: Let history trim input
Lucas Werkmeister [Thu, 11 Feb 2021 18:35:07 +0000 (19:35 +0100)]
runDialog: Let history trim input

Checking whether the item is empty is now the history’s job, per the
previous commit. The history also returns the trimmed input for us, so
we can avoid doing that work twice.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>

5 years agohistory: Trim input and ignore if empty
Lucas Werkmeister [Mon, 8 Feb 2021 21:20:42 +0000 (22:20 +0100)]
history: Trim input and ignore if empty

This ports the runDialog changes of [1] to the underlying history
component, where they can benefit looking glass as well: the history is
now responsible for trimming the input and deciding that it shouldn’t be
stored if empty. (Note that _setPrevItem and _setNextItem already
skipped updating the history if the entry was empty.)

Since both users, runDialog and lookingGlass, also need the trimmed
input for other reasons – runDialog to avoid issues when interpreting
the command as a file path (if it can’t be executed as a command),
lookingGlass to decide whether a command should be run at all – have
addItem return the trimmed input. (runDialog and lookingGlass are not
yet changed to take advantage of this – that will be done in separate
commits.)

[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>

5 years agohistory: Use strict equality checks
Lucas Werkmeister [Thu, 11 Feb 2021 22:28:55 +0000 (23:28 +0100)]
history: Use strict equality checks

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>

5 years agoHC: Set legible app icons for window thumbnails
Jakub Steiner [Mon, 8 Feb 2021 15:28:20 +0000 (16:28 +0100)]
HC: Set legible app icons for window thumbnails

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3692

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1657>

5 years agogdm: Restart only the service that failed at verification-failure
Marco Trevisan (Treviño) [Tue, 2 Feb 2021 16:57:45 +0000 (17:57 +0100)]
gdm: Restart only the service that failed at verification-failure

When verification failed using a specific authentication service we're
currently restarting the whole user authentication system, which leads
to lots of unneeded operations (reinitializing a new user verifier proxy,
restarting all the gdm workers with the relative PAM modules and so on).
And this makes also debugging of login problems more complicated, given
we're cluttering the journal with repeated data.

However, at reauthentication failure GDM has already set up for us an
user verifier that we can use reuse to start only the service that had a
failure. So when possible, just start a new service instead of rebooting
the whole authorization process.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>

5 years agogdm: Pass source serviceName to verification failures
Marco Trevisan (Treviño) [Mon, 1 Feb 2021 18:36:49 +0000 (19:36 +0100)]
gdm: Pass source serviceName to verification failures

Depending on the service name we got the failure from we could react
differently, so let's pass the value to the verification failure
handler.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>

5 years agogdm: Ensure we cancel all the previously running services on auth retry
Marco Trevisan (Treviño) [Tue, 2 Feb 2021 16:29:29 +0000 (17:29 +0100)]
gdm: Ensure we cancel all the previously running services on auth retry

When retrying the authentication we should make sure that all the
previously initiated services are stopped in order to begin a new
authentication session with all the configured services.

Unfortunately at the current state we only dispose the currently used
user verifier, but we don't make it to stop all the relative gdm workers
and then they'll stay around potentially blocking any further usage of
them (as it happens with the fingerprint one, that has unique access to
the device).

So, cancel the currently running authentication before starting a new
one if we're explicitly retrying.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1622>